Hello, I wanted to write about the things I'm improving in our GUI library, but I realized, that the important part is to explain what is the motivation to do so. So let me present the history of Factorio GUI.
Blog thoughts Klonan As the time goes on, the nature of our weekly FFF post has changed. At the very beginning (FFF-1) it was to let people know that "we're still alive and working on the game", and over time we've grown into covering a range of different topics: Communicating our progress and roadmap of the next releases. Showing new features and gathering community feedback on them. Diving into the technical side of game development and particular challenges we face. 'Meta-posts' about the company and the changes outside of the game. Community spotlights and interesting Factorio related news. It is always an interesting challenge each week to determine what topics we might be able to cover in the FFF. During the weeks of rapid development the FFF can feel like a triumphant reveal of what we have been working on, and we excitedly await the community response. Other times, such as when most of the team is on bugfixing, we can take the oppourtunity to explore other points of discussion, such as the marketing post last week. The graph of the FFF readership over the last year is quite informative to look into: We had a good run back in January and February, we had week after week of really interesting posts and a build-up of excitement for the 0.17 release. Now after the release, the readership has stabilized at around 40-45,000 views a week (note, that the graph does not include people reading the blog post through Steam). The FFF is close to its 300th post now, with no signs of stopping soon, and the continued audience of dedicated readers each week help to keep us on track and focused on our quest towards 1.0. As we get closer to completion of the game, the general nature of the blog post will no doubt change even further. The good times of showing a new feature each week might be over, but I hope we will be able to provide interesting insights into the game and our development processes. I would also like to thank all the players/readers who share their thoughts with us each week, it is really great to have so much support and care for our project.
Fluid mixing saga Dominik Hello Factorians, Today I would like to talk to you about my favourite subject - fluid mixing and its prevention. It is a new mechanic introduced in 0.17 that seemed quite simple at first, but has been giving me nightmares ever since. A while ago I took on the task of updating the fluid system (FFF-260). The way it works in 0.16 is that the fluid boxes (the thing that holds the fluid and is contained in entities like pipes or refineries) had no organisation whatsoever except their connections. They would sit there and do nothing and then once per update send fluid somewhere. It had it's issues especially with symmetry, and when you happened to put some fluid where it did not belong, you could end up requiring major demolition works. My task was to develop a better algorithm to move the fluids, and a very very optional side task I had in mind was to do something about the fluids getting to wrong places and mixing. We started by organizing the fluid boxes into systems (connected FBs make a system) managed by a special fluid manager, and optimizing the heck out of it (FFF-271). Soon after, I started working on the new algorithm and anti fluid-mixing. Until then nobody really considered preventing the fluid mixing seriously as it did not seem possible. But when I thought about it, it did not seem that hard. The idea is to simply not allow any action that would lead to fluids getting where they are not supposed to go. When you build a steam pipeline, you should not need nor want it to touch another fluid. In principle, it would only require a few quite realistic mechanisms: A connected block of fluid boxes would either be fluid-free, or it would be locked to one fluid. Two such blocks can connect only if they are compatible - either one has no fluid lock, or they have the same fluid. An assembler can only set a recipe if it is compatible with the fluid locks on its fluid boxes. Have a migration from old saves that can contain mixing. By creating the fluid systems right before, number 1 was almost finished and we only needed to assign the lock. It would be set either by a fluid, or by a 'filter', which is a fluidbox that is set to use a fluid - such as a water pump using water, or assembler having some inputs/outputs given by a recipe. After a while I had both the fluid algorithm and the mixing done (FFF-274). The mixing was not that easy (like 5x more complicated) but it worked pretty well. As for the fluid algorithm, V453000 and Twinsen found some issues with waves on a macro scale, and because it was right before releasing the 0.17 experimental, we decided to hold it off on it for the time being (we have a new version now that seems okay, but has to wait for 0.17 becoming stable first). The mixing made it through though and seemed quite finished. It turned out that the work on it was at most one tenth complete. Some difficulties appeared already before the initial release, but that was only a hint of what would come later. One by one, then ten by ten, bugs started coming. The problem is that as often as not, they were not just little issues with simple fixes. Instead, over and over, they turned the current solution on its head and the code had to be completely rewritten in order to account for the new case. As of now, almost exactly half a year and many rewrites later, it is still not fully bug free. The number one issue was with Assembling machines. It turned out that their code was pretty messy and does not simply allow the checks I needed, so it had to be refactored. The next problem was that the check was not only required when setting a recipe on an existing assembler - as I naively thought - but in about one million different situations I would not dream existed. Building a fixed recipe assembler. Reviving an assembler. Rotating. Blueprint of an assembler. Blueprint with a recipe and a rotation placed over a ghost with a non-default rotation during a full moon. Teleport. Script building. Copy-paste settings. Any combination of these. Pretty much every case would go through different paths in the code and behave entirely differently. Fixing one would break another and so tons of tests had to be written. When these cases finally worked, it turned out that doing these operations when they fail (e.g. can’t rotate because it would cause mixing) brings another wave of issues. And then mods come and the complexity multiplies. All this, although in a more simple form, had to be done for all other entities that can use fluid too, such as inserters (mods...). Another number one issue are underground connections. When playing, you would not think twice about them but on a closer look they are all but simple. They have this (cough) uncomfortable feature (want to shoot myself) that you can build another underground pipe between them (or take it out) and a complex reconnection logic jumps in. It means that based on building order, connections are established and reestablished differently. This is a big thing when building a blueprint with many pipes, or loading a save game. But the largest issue is one tiny corner case with huge implications. Have two underground pipes that have different fluids, but are split by a third, and it gets removed. Until now mixing was theoretically completely avoidable, but here it was and there was nothing to stop it. As a result, a new concept is introduced - a blocked connection. An underground connection that would normally connect but can’t. Establishing it is the easier part. But when does it get fixed? An entity miles away gets rotated, that splits a fluid system, disconnecting the blocked connection from a fluid filter on the other side, and the connection should unblock. But even something as simple as a rotation contains fluid fixes and re-establishing of fluid boxes and if it fails, it still fixes the blocked connection in the process and it can’t be undone... You get the picture. And we are still talking about underground pipes, while anything can have underground connections, including said assemblers, which the previous code did not consider at all. The complexity just goes deeper and deeper, and Rseding is probably right that we should have never gone this way at all. So the bug fixing has been basically running in circles - clearing one batch of bugs, thinking that those were the last ones and the ordeal is finally over, only to find another batch (ideally from some bizzare modder idea) a few days later. Many times I wished that mods never existed. Nor multiplayer, or any players at all for that matter. About two months ago all seemed really fine, with basically no reports and just a few crashes in the automated crash reports. At that moment another nightmare materialized in the form of a talented volunteer bug tester named boskid, who took on a personal crusade to break the fluids to dust (I actually imagine him sitting in his dark room with evil laughter, dreaming about making my next day worse than the previous). In all seriousness, he has done a great deal of work with his bug testing, creating bizzare modded cases and testing scripts, and deserves a big thanks. He is actually coming to our offices next week, so follow the news for reports of developers falling out of windows. An example of a nice configuration he found (and I can’t fix). The whole time we were taking the offensive approach to mixing - crash the game when it happens - so that we know about bugs to fix them. Recently we have decided to put a stop to it and have the mixing automatically fix itself once it is detected, eyeing the end of this episode. Right now I have 3 mixing bugs on the list and I am sure those are the last, and mixing will be done (lying to myself is a way to cope with it) and the new fluid algorithm can come soon after :).
Hello. It has been a quiet week in the office, we are slowly arranging everything needed for the office moving, which (if all goes to plan) will happen 7-11th of May.
Hello, Another trains FFF!
Belt compression (kovarex) The decision of how to approach the belt compression in 0.16 was not an easy one, we were basically facing two possibilities: Splitters are the only way to reliably compress a belt. Compression is automatic everywhere (inserters, sideloading, mining drills). Non-automatic belt compression is kind of an nice example of emergent gameplay mechanic that I liked. It was not forced on players, but it allowed to get some extra efficiency if they cared enough. On other hand, the solution to the problem is kind of obvious, and having to use it in all the setups everywhere might add more repetitiveness than fun. So after some discussions, we decided to make compression automatic. But we weren't really sure how to do it. The problem is, that once the items are pseudo-randomly added to the belt, with lot of gaps not big enough for another items to fit, it is not clear how should the additional inserters compress it: The solution was, that whenever there is any gap bigger than the standard distance between items on a belt, item can be inserted there and for a (usually) brief moment, the items are squashed together closer than usual. But once the belt starts moving, the gap between the two squashed item extends to the standard size. This change required us to do some fundamental changes to the belt logic, which could introduce a lot of new problems, but since we just wanted this to be resolved in 0.16, we had to do it now. The result is, that the same setup in 0.16.25+ results in perfectly compressed belt: The belt mechanics are now easier to use, but the game also flows more nicely. The belt flow still needs to be controlled and belt balancers are still needed. As that feels to be the more interesting part of belt handling to me, I am happy with the final result.
Space science As you already know, in 0.15 we have reworked the science packs and added infinite science. More and different science packs make the game a lot more interesting. It reduces the complexity of blue science (which is great for newer players) while adding complexity later, and you now have to decide what to research first, especially with the more expensive game modes (which is interesting for advanced players), and infinite science adds something to do forever in the game. However, one of my biggest complaints about Factorio always was that the rocket has no purpose, even though it is being propagated at all the points as the final step of the game. It is said at the trailer, at the introduction of freeplay, and by being the most advanced research, everything seems like it’s the thing to desire, but when I launched it for the first time and seeing the victory screen, I was feeling like "And now what...". For me there is one main reason why Factorio is so awesome and why I can forget myself playing until 4 a.m., and that reason is the infinite loop of 'there is always a bottleneck', you always need to fix something, you have not enough power, or your production of a particular product is insufficient etc. When you launch the rocket, you escape from this loop because it doesn’t lead anywhere. As we can see, we have learned to take the rocket as a measurable resource sink to quantify the size of our factories, which is great, but I think it makes sense to us only because we got used to it, not because it made sense in the first place, or at least it didn’t to me. Now when 0.15 adds infinite research, I started to ask myself why would I launch the rocket at all, and I have seen many of you ask similar questions. To compare the two, the infinite science is also quantifiable as I can see the amount I produced in the production screen, it also has an interesting crafting recipe (rocket parts vs. all science packs together), and it is also an infinite resource sink. The main difference is, the infinite research is actually useful. This is where the space science comes into play. We now have a space science pack, obtained by launching a rocket. You get 1000 of these science packs per rocket, and every infinite research requires these science packs. Such a simple feature, but it closes the infinite game loop again. But of course in case you want to just launch rockets without worrying about science, you can still do that, just like previously. We have also added more infinite researches, so now apart from worker robot speed, combat robot follower count and mining productivity bonus researches, we also have all of the combative damage upgrades infinite (not shooting speed as that would get ridiculous sooner or later), however their prices increase exponentially to prevent it from getting too extreme. The rocket has to have a satellite in order to get the science packs (the rocket has to be able send back the discoveries, right?). The rocket silo now has an auto-launch checkbox so you can launch them automatically, and the launch is only going to happen when you insert satellite. So you can control the inserter with satellite to only launch rockets when you need the science packs automatically through circuit network. Of course we also added support for mods, so you can define what do you get from sending a rocket, and depending on what you put in the rocket - say, if you put a tank into the rocket, you receive 100 raw fish, because that would make perfect sense. We can build up on this concept in the future, but for now this already brings a lot of sense to the game as it is. As a bonus, here is a album of my factory where I tested the infinite science concept.
Steam Awards (Klonan) Steam has opened up the nominations for this years Steam Awards. Last year Factorio was actually selected as a nominee for the 'Haunts My Dreams' award. There is a category this year for 'Best Developer', and many in the community have wanted to nominate us for that category. Unfortunately to be eligible, we would need to have a developer page set up on Steam. We had some discussions, and decided to wait until we have a final 'Wube Software' logo and theme finalized before setting up a developer page. This means you won't be able to vote for us as best developer this year... This doesn't meant that you can't nominate Factorio for one of the categories, and there has already been some discussion on the subreddit about which games people are voting for.
The main menu rework Twinsen Up until I looked at the source code, I was always confused about the differences between "Start campaign", "New game" and "Scenarios". New game seems like the same thing as "Scenarios"->"Freeplay", but are there any differences? We then later added a few more bonus scenarios, but they are hidden in the scenarios menu, with no explanation about what each is, what to expect or if it works in multiplayer. I believe it's very important to communicate to new players information about the game's content. It's also important to show that freeplay is the intended way to play. So all this prompted me to rework the main menu a bit. I started with the structure. The structure always seemed odd to me, compared to what I'm used to from other games. Important options like "Load game" are lost among options that are never used (like "Replay game"). So I came up with a new structure. It looks like this: Continue Single player New game Load game Multiplayer Host new game Host saved game Browse public games Browse LAN games Connect to address Map Editor New scenario Convert save Settings ... Mods About The first new thing to notice is the "Continue" button. Since "start the game and continue my last save" is probably the most common thing players will do, it makes sense that there is an option for this right at the top of the main menu. The button will contain the name of your latest save. Pressing it will immediately load the game and get you in game. Due to implementation complications, for now it only handles save games and it will NOT connect you to the last server you played on if your last play session was multiplayer, but I might implement that if it's highly requested. Next, everything was grouped into either Single player or Multiplayer. There are much fewer options, since "Replay game" was moved as a small button in "Load Game", and every way to start playing the game was moved to the new "New Game" GUI. The "New game" GUI shows all the ways to play the game. It also groups them nicely, places freeplay on top, shows a description and even a nice image. This GUI is used for new game, multiplayer hosting and map editor, thus simplifying the menu quite a bit. For modders, scenarios can now contain a description.json file. In the file "order" determines the sorting in the New Game GUI; "multiplayer-compatible" determines whether the scenario is shown when trying to host multiplayer games. "multiplayer-compatible" was added to description.json file of campaigns also.
